Modern enterprises, particularly technology companies, often provide benefits that are sold or given to their customers or partners. For example, an enterprise's customers, or selected subsets of customers, may be entitled to receive product upgrades or updates or product support. These examples are typical in the software industry, for example. Similarly, an enterprise's partners may be entitled to receive selected benefits. For example, rather common “partnerships” are developers that write software applications, or develop Web pages, or similar activities using the sponsoring business's development tools. The sponsoring business may provide benefits to its partners that supplement or otherwise augment the business's products and make their application by the user more efficacious. An apparent example is technical support.
As the size of a sponsoring business and its customer and/partner base increases, customer relationship management and partner relationship management requirements become more complex. Benefits to which a particular customer or partner are entitled (or simply, “entitlements”) may vary across customers and/or partners. Additionally, if the customer or partner is itself a large enterprise, the type and quantity of entitlements may differ among the various entities and individuals within the customer or partner. As a consequence, a framework for defining customer/partner benefits and associating particular benefits with parties entitled to access or use them have evolved.
FIG. 1 schematically illustrates an exemplary association of a set of services, service 102, service 104, service 106, service 108 and service 110 and a set of recipients entitled to receive selected subsets of those services, denoted recipient 1-recipient 4. As discussed hereinabove, exemplary services might include technical support, software upgrades, white papers, ancillary software packages, etc. For purposes herein, the particular type or nature of the services is not limiting. Note too, that each service may include a set of objects which might represent Web content, for example, denoted in FIG. 1 in list notation, that is a parentheses-delimited set. Thus, service 102 includes objects (a, b) 112. Service 104 includes a single object 114 (c), service 106, includes three objects (d, e, f) 116. Service 108 includes the single object (g) 118 and service 110 includes objects (a, h) 120. Note that objects are reusable. In other words, an object may be included in multiple services. A service, as used herein, is an abstraction that represents an atomic deliverable to a customer via a benefit delivery system, and maps between the definition of the service and the actual delivery of the service by the benefit delivery system. Thus, for example, a deliverable may be represented in a database as a service with attributes that may include a unique identifier, a short name and a description that may be used to display information about the deliverable to users on a web site, for example.
Services may be combined into a package which may represent an atomic entitled benefit. That is a benefit that has a single set of criteria that once met, permits an entitled recipient to access the services within the package. In the exemplary entitlement structure 100 in FIG. 1, services have been combined into three packages, package 122, package 124 and package 126. Package 122 includes services 102 and 106. Package 124 includes services 104, 106 and 108, and package 126 includes services 108 and 110. An example of a package might be a technical support benefit that may include services which deliver read access to various technology forums, and the ability to ask electronic questions and receive electronic responses. Another package might include some or all of these same services but add a voice support service.
As previously described, a package may represent an atomic entitled benefit, that is, a recipient is entitled to receive services on a per package basis. In exemplary structure 100, entitlement 128 entitles recipient 1 to package 122, entitlement 130 entitles recipient 2 to packages 122 and 124, entitlement 132 entitles recipient 3 to packages 122, 124 and 126 and entitlement 134 entitles recipient 4 to package 126. The associated services, all of which are accessible to the corresponding recipient are indicated in the list notation above each of the respective entitlements 128-134. Thus, for example, recipient 2 via entitlement 130 may access services (a, b, c, d, e, f, g).
Entitlements associate packages of services with recipients. In managing customer and/or partner relationships in a large enterprise, the creation of the entitlements, and the verification of access requests against the entitlements can represent a significant management burden. In particular, as previously noted, the customer and partner base may itself include entities that are also large and include a multiplicity of entities within the enterprise, at least some of which may be entitled to different benefit packages. Additionally, it may be desirable to refine the granularity of the entitlements within a particular organization unit of a beneficiary enterprise. Consequently, there is a need in the art for managing entitlements associated with packages of services and in particular, there is a need in the art for mechanisms by which such entitlements may be flexibly configured without recoding the entitlement system. In other words, a mechanism by which entitlements associated with a package may be readily configured to account for, say, a change in circumstances with respect to the delivery of services within a package. For example, a change in a regulatory or other legal requirement in a particular geographic location may implicate the delivery of one or more services within a package and it may be desirable to configure the entitlements associated with that package accordingly.